Toward a Marketplace Infrastructure for Virtual Organisations

This paper is a progress report on our work to create an open, flexible infrastructure to support virtual organisations through knowledge fusion technology. Knowledge fusion refers to the process of locating and extracting knowledge from multiple, heterogeneous on-line sources, and transforming it so that the union of the knowledge can be applied in problemsolving. When applied in enterprise-to-enterprise lectronic commerce, the knowledge fusion process allows partners to exchange rich business information, and act in an agile and coordinated manner. As an example, we have created a demonstration application in the domain of telecommunications service provision, in collaboration with British Telecom. In our current work, we are extending our infrastructure to include mechanisms to regulate the operational marketplace, to ensure that a virtual organisation complies with the rules of the market. Introduction and Motivation At the AAAI’99 workshop on Artificial Intelligence for Electronic Commerce we reported on the KRAFT project (Knowledge Reuse And Fusion/Transformation) and its application to supporting virtual organisations (Preece, Gray, ~ Hui 1999). KRAFT is intended to be used in an extranet situation where partner organisations exchange business knowledge in a constraint-based format, and form dynamic alliances by finding a mutually-beneficial solution to their various requirement constraints. In KRAFT, constraints are expressed against an object data model, and exchanged using a standard agent communication language (Preece et al. 1999). The core KRAFT architecture has the facilities for: ̄ locating appropriate on-line sources of knowledge; ̄ transforming heterogeneous knowledge to a homogeneous constraint interchange format; ̄ fusing the constraints with associated data to form a dynamically-composed constraint satisfaction problem (CSP); ̄ harnessing existing constraint solver engines to compute CSP solutions. Recent work in the study of virtual organisations has lead to a commonly-accepted life-cycle for these organisations: 1. needs identification: definition of the services or products provided by the virtual organisation; 2. partner selection: composition of the group of partners that, together, can meet the identified needs; 3. operation: conduct of the transactions by which the services or products are provided by the partners; 4. dissolution: disbanding of the group of partners, including any final settlement of payment or other closing transactions. The KRAFT architecture supports this life-cycle as follows: 1. needs identification: customers’ requirements can be expressed readily and naturally as a set of constraints; likewise, the capabilities of service and product providers can be expressed using constraints; 2. partner selection: by combining and checking the constraints from customers and service/product providers, a virtual organisation can be composed that has the potential to meet the customers’ requirements; 3. operation: additional constraints will appear during the process of working to satisfy a specific customer’s requirements -these may come from the customer itself, or from any of the suppliers; the constraintsolving process can easily accommodate these constraints, dynamically; 4. dissolution: the constraint solving process will yield a set of results that include the conditions that must be met when the virtual organisation is disbanded. The remainder of this paper is organised as follows: the next section reviews the KRAFT architecture; then, we present a waikthrough of a demonstration KRAFT application in the domain of telecommunications service provision (develped with British Telecorn); finally, we discuss ongoing work to add facilities necessary to operate regulated electronic markets within KRAFT. 54 From: AAAI Technical Report WS-00-04. Compilation copyright © 2000, AAAI (www.aaai.org). All rights reserved. Review of the KRAFT Architecture The KRAFT architecture was conceived to support configuration design applications involving multiple component vendors with heterogeneous knowledge and data models. This kind of application turns out to be very general, covering not only the obvious manufacturing-type applications (for example, configuration of personal computers or telecommunications network equipment) but also service-type applications such as travel planning (for example, composing package holidays or business trips involving flights, ground travel connections, and hotels) and knowledge management (for example, selecting and combining business rules from multiple heterogeneous knowledge and databases on a corporate intranet). Constraints in KRAFT The most common modern approach to configuration design problems is to tackle them as constraint satisfaction problems (Freuder & Faltings 1999). Where components in the design will come from a number of different vendors, the domains of many of the variables in the CSP are entities stored in each vendor’s local product database catalogue. Many of the constraints in the CSP will be on these entity types, defining how the components can be used in configured designs. Some constraints will refer to related instances of other entity types, whose values must be extracted from some other vendor’s database and checked for compatibility. Incompatibilities often arise due to the presence of subtle assumptions in vendor’s product catalogues -in traditional printed catalogues, these assumptions often appear as "small print"; hence, we refer to this kind of knowledge in KRAFT as small print constraints. As an example, the product catalogue for (fictitious) disk drive vendor, Storage Inc, may have the following small print associated with each of its range of Zip disk drives: this Zip disk drive requires a PC with a USB-type port. This kind of small print can readily be expressed as a constraint which can be exchanged with other vendors and resellers: constrain each d in disk_drive such that name(vendor(d)) "Storage Inc" and type(d) = "Zip" at least 1 p in ports(host_pc(d)) to have type(p) = "USB"; Similarly to other knowledge-interchange systems (Neches et al. 1991), KRAFT requires participating agents to transform their local knowledge to a well-known format, and use a shared ontology of terms; the above constraint is expressed in the KRAFT Constraint Interchange Format (CIF), the terms of a shared ontology for PC system configuration. These transformations are implemented within a wrapper agent for each individual vendor, as part of the setting-up needed for the vendor to join the KRAFT network. Once transformed, the small print constraints can be fused together with other constraints from various sources, as shown in Figure 1. In a typical configuration design application, some constraints will be provided by the customer; others will come from the vendors as discussed above; there will also be constraints coming from the service provider who will act as the configurator of the product or service provided by the application. Typically, the configurator service-provider will be a value-adding reseller from the point-of-view of the component vendors. Note that there may be multiple configurators, each providing a different product or service; also, the design process may have additional stages, where one reseller sells to another reseller, each adding their own constraints to the final product or service. Details of how the constraint fusion process operates within the KRAFT architecture are given in (Preece et al. 1999).